Closed Bug 87472 Opened 24 years ago Closed 24 years ago

memory from closed windows not freed until shutdown

Categories

(SeaMonkey :: General, defect, P1)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED INVALID
mozilla0.9.3

People

(Reporter: dbaron, Assigned: dbaron)

Details

(Keywords: memory-leak, top-memory-leak)

Attachments

(2 files)

In bug 84136, I wrote: | However, even with that patch, if I start mozilla (debug), I see 42MB memory | usage, and if I open 6 more windows I see memory usage go up to 52MB, and it | doesn't come back down when I close those Windows. However, according to our | leak detection tools we are freeing the memory before we exit. So what I'm | seeing is probably the hardest type of leak to diagnose -- one where we free | memory later than we should have, but do free it. (It's hard for a leak | detection tool to know when something *should* have been freed and detect that | it was freed later than it should have been. Many objects are supposed to be | very short-lived and some are supposed to exist for the entire lifetime of the | program.) Anyway, I'll look into it a bit more... I did the following test in both a debug and opt build: * start mozilla * click my default profile in the profile manager * open 6 new windows by hitting Ctrl-N in the newest window * close the windows by clicking the X in the corner in the reverse order they were opened In my debug build I saw memory use increase (based on top) from about 42M to 52M, and not fall after I closed all but the last window. In my opt build, I saw the same, except the numbers were 22M and 30M. (All on Linux.) When I used about:bloat?clear in the first window, then opened the windows, and then used about:bloat in that window at the end, I saw the differences in memory use that I'll attach. (Note that objects logged by nsTraceRefcnt probably account for something like 20% of our heap.) When I did the same thing except loading about:bloat in place of about:bloat?clear, I saw very few leaks logged by nsTraceRefcnt after the app shut down. (They had to be separate runs because about:blank?clear messes up the stats.) I'll attach both runs to the bug.
Status: NEW → ASSIGNED
Keywords: mlk, topmlk
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
OK, I fell into the "top" trap from the other bug. I think what I was seeing was more fragmentation and such than anything else -- when I reopened the 6 windows again memory use didn't increase significantly. I suspect my "memory change" stats may have changed a bit if I'd opened and closed a new window before doing the clear or if I'd used open web location before doing the clear. However, typing in the URL bar and even sometimes open web location are so totally broken right now that I can't tell.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: